Security

Content Studio uses several layers of security. The first level is that of the Web server (Internet Information services, IIS). It receives requests from callers and can be configured to accept requests only from a specific IP-address or a specific set of addresses. In addition to that, the site can be set to accept un-identified anonymous users or users identified by one or more of the supported identification methods.

In IIS 6 and later (used with Windows Server 2003) all Web application uses application pools that runs with very limited permissions in the operating system. This approach limits the attack surface that IIS exposes in case of a hostile take-over (for example through a buffer overflow security flaw in the IIS). In IIS 7, used by Windows Vista and Windows Server 2008, this approach has been even more refined thus making the system even more secure.

When the request reaches Content Studio, ASP.NET and the .NET Framework adds a second layer of security to the system. ASP.NET runs in a secure managed environment where the executing code has no direct access what so ever to the underlying memory and hardware thus making it impossible to execute unauthorized code.

Finally, Content Studio itself adds a third layer of security to the system by handling identification of the calling users and provides a sophisticated access control mechanism that regulates access to virtually everything you see on the web page and every possible support object defined by Content Studio. The Content Studio Web sites all communicates with the underlying system and data services through the Content Studio Server.

Content Studio Server runs as a regular service with the lowest possible operating system privileges and by using stored procedures to communicate with the data base the famous SQL-injection security flaw is totally eliminated. This approach makes Content Studio a very robust and secure platform for web applications; be it a public site on the Internet, an Extranet or a corporate Intranet.

The catalog

Content Studio always synchronizes its users and roles (security groups) with a catalog. The default catalogs are the Active Directory and the local security (SAM) database of the Web server. This means that Content Studio has a tight and native integration with the security system of the Windows operating system. This ensures that the security level is the same as the operating system and the components used by Content Studio.

A very convenient feature is single sign-on that comes with this tight integration, something that is particularly useful in intranet scenarios where all users are logged on to the same Active Directory.

In addition to these catalogs, it is possibly to use custom providers that enable Content Studio to identify and integrate trustees (users and roles) from virtually any external catalog such as Novell NDS or even homemade systems.

User identification

When using the built in Windows catalog the users are either anonymous or authenticated with an available Windows or Active Directory user account. Content Studio can identify the calling user by using the regular impersonification technique. Content Studio can get read access to the caller Access Token. An Access Token is an object that exists in every process in the Microsoft Windows operating system and the token is created by the logon authority when the user logs on, either directly on the console, as a batch or service process or through the web browser via Internet Information Server, IIS.

When using IIS on the Web page, IIS logs on the user either by using the supplied user name and password (clear text logon) or by using the access token supplied by the Web Browser (integrated security). In the former case the user name and password are sent as clear text in the request header, thus making this kind of logon procedure extremely vulnerable to network sniffers etc.

The advantage with the clear text approach is that it works with any web browser and through firewalls. When using this technique you always should use a secure and encrypted connection, such as SSL, when communicating between the client and the server. The integrated security model is far more secure since no password is transmitted over the network or the Internet but a secure communication is recommended whenever the web site is public. Additionally, the integrated security logon method is very often stopped by firewalls and reverted to plain-text as a last resort.

The Access Token contains a list of all groups that the logon authority determined at logon-time that the particular user is a member of. By comparing this list with the list of groups already registered and known to Content Studio, the system can map the user's account to all the matching groups. During the identification process Content Studio also registers the incoming user in its internal user table or updates the user's properties if the user already exists in Content Studio. Eventually, when the process is finished, the user receives her dynamic session identifier, SessionID, that will identify her during the rest of the web session.

Users and roles

In Content Studio, just like in the operating system, each user and security group (trustee) is identified by using a security identifier. A SID is a dynamic data identifier that is unique within the system and the network and in order to be able to work with trustees they have to be registered in Content Studio. While users are registered automatically when they are identified, groups have to be registered manually.

This behavior makes sense, since in a network there are a lot of groups that have no interest on the Web site or on the corporate Intranet. In addition to this, manually registering groups helps administrators to maintain a high level of security since, by default, no-one besides members of the local administrators group, has access to Content Studio. By registering groups that are relevant to the Web site or the Intranet the administrator can "open up" Content Studio in a detailed and controlled way, giving access only to the users and groups that need it.

Security groups from the local SAM database or from the Active Directory can be registered directly from the Content Studio administrative interface. Any groups found in external catalogs must be registered by using a customized web application or a specially crafted program (custom logon provider).

Allowed file types

Starting with Content Studio version 5.1 it is possible to specify what type of files (based on their extension) that can be stored in a category. For example you can specify that a category only can contain image files (such as JPEG and GIF) by supplying a list of file extensions that are allowed (ex. .jpg,.gif). When such a policy is applied Content Studio checks the extension when a document is saved and stops any attempt to break this rule. In the category properties dialog you will find a new input field where this file extension policy can be entered. This policy is a comma delimited list of file extensions where each file extension must start with a period (.).

After upgrade, all existing categories will have the .* rule applied and this rule allows any file type to be saved thus ensuring backwards compatibility.
EPT document are a special case. Starting with Content Studio version 5.1, for security reasons, the default extensions is .ept but the old .xml file extensions is allowed for backwards compatibility. When upgrading from Content Studio 5.0 the policy .ept,.xml will be applied to any EPT category.

The order of the policy string is significant since the Content Studio Webbitor will use the first item in the policy list as the default file extension for the category. However, the author of the document can change the extension to any of the allowed extensions at any time.

Security configuration

After the installation process the administrator need to register security groups to work with and set these rights appropriately. For example, a simple intranet might have five main roles.

• Visitors
• Editors
• Publishers
• Developers
• Administrators

In this example, an administrator might do the following basic security configuration:

• Create three new security groups in the Active Directory or on the locale web server named Editors, Publishers and Developers.
• Make the persons that should develop the web site members in the Developers group
• All site content writers should be members in Editors group
• The persons responsible for the published content of the web site should be members in both the Editors and the Publishers groups.
• Make everyone that should be able to read the content of the new Intranet a member of the Visitors group. Often, this group can be substituted by the Everyone or Users groups, but in this case we choose to have a specific group for the Intranet visitors.

Register these groups in Content Studio and set the following global rights for registered groups.

If the editors and publishes does not have a good knowledge of HTML programming you might not want to give them the AdvancedEdit right. This is especially true if the web site should be developed according to the accessibility rules and makes extensive use of Cascading Style Sheets (CSS). This type of web site is very easy to destroy, especially if you are not an experienced HTML developer. The Developers group is in this fictive case a group of professional Content Studio and Web developers.

In the document tree, the administrator now should create two containers, one, named Admin, for the administrator part of the site and the other, name Content, for the actual content of the web site. The Admin container will be the root container of all edit and presentation templates, main pages, user controls, master pages, AS-components and include documents. Also, here you will find the personal program code written by the developer. In the Content container and its sub containers you will find all content documents such as EPT-documents and non critical include documents.

The administrator now opens the web site to the personnel by setting the following permissions on the Web site root folder.

• Visitors - Read on site
• Administrators - Full Control; Read on site
• Developers - Read
• Editors - Read
• Publishers - Read

To enable the Developer group to do their job the administrator now sets the following permissions on the Admin folder:

• Developers - Delete; Write/Create; Terminate Workflow; Publish; Manage Container

If the site developers will write blocks of code in documents using the "Insert script" AS-component the administrator must allow them to use this component by opening up the security directly on the component for the Developers group. The only permission needed in order to use an AS-component is the Read permission. The Security descriptor on this component is protected from inheritance by default and accessible only to members of the Administrators group and must be "opened" to everyone that needs to directly edit documents that contains this component.

To enable the Publishers and Editors groups to do their job, the administrator now sets the following permissions on the Content folder:

• Developers - Delete; Write/Create; Terminate Workflow; Publish; Manage Container
• Editors - Delete; Write/Create
• Publishers - Delete; Write/Create; Terminate Workflow; Publish;

Using custom logon providers

When using a custom logon provider, the web site must be set up to run anonymously. In that case, all users are the same to the operating system and the users and its group memberships are entirely controlled by the provider. The logon procure will not be managed by the standard web browser mechanisms. Instead, a certain logon page must be provided that retrieves a proof of a successful logon that can be presented to the logon provider.

Content Studio will not be able to use the normal authentication process. Instead, the custom provider will perform identification and group mapping process. Writing and installing a custom logon provider is an advanced task that has been thoroughly documented in the article "How to write a custom logon provider".

Developing secure Web sites

Developing secure websites is very much a matter of giving the attacker as little information as possible about your Web site and being very carefully during the development process keeping security in mind all the time.

Always turn debugging off and custom error messages on

The detailed error messages that will be displayed to the caller if the Custom Errors are turned Off can, together with debug information, give the intruder very valuable information about the internal implementation of the Web site.

 

Do not make any personnel a member of a group with administrative privileges.

Users with administrative privileges can do anything with your web server and the only persons with this privilege should be the persons maintaining the server. The best idea is to use a special account for administrative tasks.

Developers do not need to be administrators on the server, use the GlobalGroupAdmin group right to make your developers administrators in Content Studio while they still are regular users on the server.

Disable the local administrators account

Any attacker that has even the lowest privileges on the server can easily locate the built in administrators account because it has security identifier whose last part is well known. Instead create a regular administrative account with a name that does reveal that is has this privilege. Set a very strong password with at least 10 characters for this account. Weak passwords can be cracked with a brute force attack.

 

Always use secure connections to the administrative interface

If the administrative interface should be available in the public internet always use a secure connection. This can be a connection through using VPN or regular SSL. If the connection is not secure there are no guarantees that an intruder cannot listen to the traffic sent and extract passwords and usernames.

 

Do not use Windows accounts for external users

If these credentials leek to an intruder it will be much easier for an attacker to access your web site. Instead, use Forms login for these kinds of users or the traditional EPT user credentials but be sure to protect sensitive user data from illegitimate viewing.

 

Never store passwords in clear text

A popular an effective way of implementing custom logins in Content Studio is to store user data in EPT documents including user names and passwords. You should always protect these kinds of information by either storing the passwords encrypted or one-way hashed.

 

Never use the EPT user account that can be connected to real Windows accounts

The EPT credentials are not as strong as the Windows credentials and you should never reveal any information that can connect the EPT user with any real Windows user, this can be very valuable information for an intruder.

 

Never reveal the name of the underlying file for EPT documents

In Content Studio all documents are stored on disc as well and EPT documents (and other documents as well) have their file names as machine generated identifies GUIDS that are virtually impossible to guess. All access to data documents must be done through their document id:s so that they can be protected by the sophisticated access control system of Content Studio.
If you for some reason reveal the underlying file name a user might be able to view the complete Xml data of the EPT document provided that the caller has access to the actual file. This can reveal information that is not intended to be presented.

Always connect a presentation template to an EPT document category

If the EPT category has a presentation template connected to it the Ept document is not returned to the client in its original xml format but formatted through the default presentation template. However, if no presentation template is connected the client can see the underlying xml data, something that can be unwanted. An intruder will most likely enumerate through all document id:s (default.aspx?id=NNNN) until unprotected documents are found.

 

Do not give more permissions than necessary to users and groups

As a general rule you could be very restrictive with permission for users and groups in Content Studio, no one should have more permission that necessary in order for the administrator responsible for the web site to remain in control of the Web site.

 

Do not give more global rights to users that needed

Global rights can only be given to registered groups in Content Studio and specifies what the members of that group can do on the entire site. As a general rule you should be very restrictive with these rights. For example, if a group has the WriteActiveContent right set, its members can write server side code in any document where they have WRITE permissions and in addition to this, they can upload any type of files, even .ASPX-files, files that can be executed on the server side.

 

Regularly test the Web site with low privileged user accounts

During development you should test all kinds of low privileged user accounts scenarios so that you do not end up with a site that need all its editors to the administrators just because it is too difficult or takes too long to find out where the permission problems are.

Encrypted cookies

Starting with Content Studio version 5.1 you can encrypt cookies that contain sensitive data such as the Content Studio session identifier. This encryption is implemented as an Http module that encrypts the outgoing cookie to the client and decrypts incoming cookies from the client. By default only the CS_UserSessionId cookie is encrypted and this prevents possible identity spoofing attacks when an intruder injects a fake session identifier into his cookies. An encrypted cookie is configured in the web.config file under a new custom section , <ContentStudio>.

<configuration>
    <configSections>
        <sectionGroup name="ContentStudio">
            <sectionGroup name="CookieEncryptionModule">
                <section name="Settings" 
                         type="ContentStudio.HttpModules.CookieEncryptionModuleConfigurationSection" />
                <section name="CookieNames" 
                         type="System.Configuration.NameValueSectionHandler" />
            </sectionGroup>
        </sectionGroup>
    </configSections>

    <ContentStudio>
        <CookieEncryptionModule>
            <Settings CookieProtection="All"
                      Enabled="true" />
            <CookieNames>
                <add key="CS_UserSessionId" value="" />
                <add key="CS_Site" value="" />
            </CookieNames>
        </CookieEncryptionModule>
    </ContentStudio>

    <!-- Other configuration elements -->

</configuration>   

Note that the value attribute is empty since it is ignored by the Http handler.
You can encrypt any cookie but it is wise to limit the number to the ones containing sensitive data.

The cookie protection will take some resources on the web server and if there is no need for cookie encryption you can remove this section in the web.config file. The administrative sub-site will inherit the settings from the site so there is no need to include this section in the web.config of the administrative site unless you have removed the configuration from the site or turned the encryption off and would like the administrative site to use cookie encryption.

Security policies

Starting with Content Studio version 5.1 there is a new policy based security layer in the product. Policies are global rules that defines rules that the Content Studio core enforces in certain security sensitive scenarios such as when creating and uploading documents and when previewing documents. A policy contain one or more rules that contains instructions of what to do and Content Studio checks these rules one at the time from top to bottom. Policies rules in Content Studio is an advanced subject that is documented more thoroughly in the article Security policies.